The CommuniGate SMTP is a server communication module supporting E-mail message transfer using the SMTP and ESMTP Internet protocols (RFC821, RFC1425, RFC1854, RFC1869) via TCP/IP networks. In addition, it supports receiving E-mail even via dial-up connections - by means of wake-up E-mails and/or the Remote Queue Starting procedure described in RFC1985 (in both the client and server modes). MIME (RFC 1341) support and various attachment encoding methods are provided within the CommuniGate Server kernel itself.
The CommuniGate SMTP is designed to support both direct and dial-up Internet connections. It allows you to run a full-featured Internet E-mail server even if you do not have a direct IP link to the Internet.
The CommuniGate SMTP module supports multi-stream communications, and it can send messages to and receive messages from several other hosts simultaneously.
The CommuniGate SMTP module can work together with the CommuniGate POP and CommuniGate IMAP modules providing complete TCP/IP Internet E-mail services.
The CommuniGate SMTP module can work together with the CommuniGate UUCP module providing both TCP/IP and UUCP Internet E-mail. The CommuniGate Router takes care of directing messages to the proper gate.
The CommuniGate SMTP module can protect the server from being used as a mail relay (for "spam"), and it can distinguish messages sent by registered users.
The CommuniGate SMTP module can accept AppleTalk connections providing mail services to both TCP/IP and AppleTalk-savvy mailers (as Claris Emailer™).
The latest version of the CommuniGate SMTP software can be obtained from:
<http://www.stalker.com>
or
<ftp://ftp.stalker.com>
To be notified about updates: send any message to <cgate-on@stalker.com>
Installation
Place the SMTP module file in the Modules folder inside the CommuniGate Folder in your System Folder. If you use the FreePPP software to link to Internet, make sure the TCP Agent applet is also placed in the Modules folder. Restart the CommuniGate Server.
Sending via Dial-up Connections
If you use a dial-up link, you may want to restrict the TCP/IP activity of your server (by means of the TCP Schedule settings). If you send a message with a recipient marked "High Priority", the system tries to establish a TCP/IP link and to send that message immediately, even if the TCP/IP activity schedule does not allow for new links at that time.
The SMTP module can use an external, "foreign" mail server (the mode most other Macintosh E-mail packages use), or it can deliver messages directly, using the DNR services.
Using Foreign Mail Servers
When the Foreign Mail Server option is used, the SMTP module connects to the specified mail host and sends all messages from its queue to that host. Since the foreign mail server host is usually "close" to your server, messages are sent quickly. But this method can cause additional delays in message delivery, since messages are queued on the foreign server and those queues can be processed slowly. The Foreign Mail Server method is recommended when your server is connected to the Internet via dial-up lines (using PPP or SLIP protocols) and you want messages to leave your server as soon as possible to keep the connection time short.
Note: when a recipient domain name is specified as an IP address, i.e. user@[12.34.56.78], the CommuniGate SMTP module delivers messages directly to the host with the IP address 12.34.56.78, even if the "Foreign mail server" option is in use. You may want to use this feature for message exchange between several CommuniGate (or other) mail servers on your LAN that does not have its own Domain Name Server, or if you use several servers with the old MacTCP software.
Note: the name of the "foreign mail server" should be the name of the real computer (as specified in an A-type DNS record), not a mail domain name. While your provider domain name can be provider.com, the name of the provider mail server can be something like mail.provider.com. Consult with your provider to get the exact name of their mail server.
Sending Messages Directly to Recipients
The DNR (Domain Name Resolver) method is the method used in "real" mail systems. For each message and address in its queue, the SMTP module uses DNS (domain name servers) to get the name and address of the host the message should be delivered to. It can be the destination host itself, or a relay host. The information about the proper relay host is stored in so-called MX records on Domain Name Servers. For each destination host several records can exist, each record having a priority value. If the relay host with the highest priority is not answering, other MX records are used and other relay hosts are tried. If no relay host is available, the message remains in the SMTP queue, and more attempts to deliver it (and all other messages to the same host) are made later.
This method allows the system to deliver a message either directly to the recipient computer or to a relay host that is "very close" to the recipient computer. Recipients can read your messages almost immediately, and your messaging system does not rely on the "foreign mail server" performance.
The "Get MX" function is not properly implemented in MacTCP, so the DNR method is disabled when the old MacTCP is installed on the CommuniGate Server computer. The Open Transport TCP does implement DNR functions correctly and the "Using Open Transport DNR" option is enabled for OT-equipped servers.
Receiving Messages via Direct Internet Links
If your system has a direct (permanent) Internet link, it can act as a regular SMTP server. Ask your provider to make sure the domain name of your system has the proper MX (Mail Exchange) records in the DNS (Domain Name System).
Specify a non-zero Channels limit in the Receiving options. Select the Wait For Connection and Always Keep Ready options.
Receiving mail via Dial-up Connections
Usually the CommuniGate POP module is used to receive mail via dial-up links. In this case, set the TCP/IP Channels in the Receiving Options to zero (see the note below).
Some providers allow their clients to receive mail via SMTP even if those clients use dial-up connections. In this case your system, as any other SMTP server, must have a static IP address assigned to it. The MX record for your server should be included into the DNS system, and one MX record should specify the provider host as the backup mail host for your domain(s).
You should specify how often the SMTP module should establish TCP/IP links to retrieve incoming mail. Select the Send Wakeup E-mail or Start Remote Queue option and specify the time interval.
If you select the Send Wakeup E-mail option, the SMTP module will send dummy messages to the specified E-mail address (usually this is a special address on your provider host). This not only forces your dial-up TCP software to establish a TCP link, but it can be used to force your provider host to start sending the messages it has collected while your Server was not connected to the Internet. This is an old method to support dial-up clients, but some providers still use it. Consult with your provider about the E-mail address you should use for wake-up.
If your provider system supports "Remote Queue Starting" (RFC1985, also known as the "ETRN" feature), then you may select the "Start Remote Queue" option and specify the name of the host that collects mail while your system is down (the name of the back-up mail server - usually it's your provider mail host). The SMTP module will contact that host at specified intervals and it will issue the special ETRN command to release all your suspended messages in that server queues, so that server starts sending the collected messages to you immediately. Consult with your provider if their mail server supports this option. This option is implemented in the CommuniGate SMTP 2.x acting as an SMTP server, in the Un*x sendmail 8.8 and later, and in some Windows NT mail servers.
Some hosts are smart enough to release your mail queue automatically when your system connects to the Internet via PPP . In this case, just use the Wait For Connections option.
The Always Keep Ready option should NOT be enabled if you use a regular PPP link. When this option is not selected, the SMTP module prepares to receive incoming messages only at specified times (at the time when a wake-up E-mail message or a Remote Queue Starting command is sent). You should select the Always Keep Ready option only if you have a direct Internet connection, or if you use an IP gateway AND you want to serve local POP/SMTP clients on your LAN.
Note: If you select non-zero number of the TCP Channels and select the Always Keep Ready option when you are using a regular PPP link, the SMTP module will force your PPP software to dial out and reconnect to the Internet immediately after the dial-up link is shut down.
Configuring
After the SMTP module is placed in the Modules folder on the Server computer, you can configure it from any workstation that has the "can configure" privilege.
• Choose SMTP from the Monitor section of the Server menu. The SMTP Monitor window appears.
• Choose Service Settings from the SMTP menu.
• Set the log level.
Note: if you select the "All Info" log level, log files will become very large very soon and the system may operate slowly when a SMTP connection is active.
Sending Options
• Set the TCP/IP Channels option. This option limits the number of outgoing SMTP connections the SMTP module can open at the same time. If you plan to use a foreign mail server, you can set this option to 1.
• Select if you want to deliver messages directly to the recipients (using the DNR services of Open Transport), or if you want to use a foreign mail server (to keep the message transfer time short). In the later case, enter the domain name of the foreign mail server (usually, it is the domain name of your provider host, see above).
• Select the Retry Every option to tell the module when it should retry to send a message if a connection fails. If you use the"via Foreign Mail Server" method, this option specifies when the module should retry to connect to the foreign server if the previous connection failed for any reason. If you use the "Directly to Recipients" method, then this option is used to suspend all messages directed to the host the SMTP module failed to connect to. Usually, SMTP systems suspend messages for 30 minutes.
• If you use the Directly to Recipients method, set the Retry option. This option limits the number of attempts the module makes to deliver a message. After the specified number of attempts is made, the message is rejected and an error report saying that "the host is not available" is sent back to the message sender.
Receiving Options
Consult with your network provider if you can get your mail via SMTP, or if you should use the POP module. If mail comes to your CommuniGate Server via UUCP only, or if you have to use a foreign POP server to get your mail, set the TCP/IP Channels option to zero.
If you should receive your incoming mail via SMTP, then other hosts will connect to your host via the Internet (TCP/IP), so set the TCP/IP Channels option to non-zero. This option limits the number of incoming TCP/IP connections the SMTP module can accept at the same time.
If you plan to use POP or IMAP mail clients with your server, you should set the number of receiving channels to non-zero: those clients use POP or IMAP protocol to retrieve mail, but all of them use SMTP to submit messages. You should have either a direct Internet connection or an IP router on your server/LAN in order to serve such clients.
If the maximum number of incoming TCP/IP channels is set to non-zero, then:
a) if the Server computer is running MacTCP, several "empty" lines appear in the SMTP monitor window: they represent TCP streams waiting for incoming connections.
b) if the Server computer is running Open Transport, an icon appears in the top part of the window indicating that a listener socket has been created. This socket is used to receive incoming connections under Open Transport.
• In the Receiving Options, set the wake-up parameters. See the details above.
Receiving via AppleTalk
The SMTP module used under OpenTransport can process incoming connections via AppleTalk (ADSP). If you have mail clients that can use both TCP/IP and AppleTalk (as Claris Emailer™), then you should set the AppleTalk Channels setting to non-zero. In this case, the SMTP module is always kept ready to receive incoming SMTP connections via the AppleTalk.
If your server is equipped with a single-user PPP software (as OT/PPP), this feature allows AppleTalk-based mailers to connect to your server without a need to have TCP/IP on your LAN:
clients submit messages to the server via AppleTalk, as they do with the native CommuniGator client appliaction. The SMTP service is published on your AppleTalk network with the same name as the domain name assigned to the CommuniGate Server. The published service type is "RRSMTP". This is the same network type as used in the Claris OfficeMail™ product, so Claris Emailer users can configure their mailers in exactly the same way as they configure them when using an OfficeMail server.
Note: publishing a name on your AppleTalk network can freeze your server computer for 10-15 seconds when the CommuniGate Server starts.
Restrictions
If your server is not supposed to receive mail from the Internet via TCP connections (the TCP/IP Channels setting in the Receiving options is set to zero), skip this section.
If your SMTP module can accept incoming TCP connections from 3-rd party POP and IMAP mailers, you may want to specify the IP addresses of your users: messages received from the specified IP addresses will be market as "local". If, for example, your CommuniGate Fax module does not allow "non-local users" to send faxes to long-distance numbers, the messages submitted from those addresses can be sent to any fax number, as all the messages submitted directly with the CommuniGator client application.
Click the Our Users button. The dialog box appears and allows you to enter the IP addresses. Each line can contain either one address in the form: 12.34.56.78, or a range of addresses in the form:
12.34.50.01-12.34.59.99 Put the IP addresses of the client workstations equipped with POP/IMAP mailers here.
Usually, you would put the address range for your entire LAN here. If you have a branch office that should have access to all the CommuniGate features without any restriction, as your local users do - put the addresses of the branch office LAN (or of the mail server on that LAN) into this list, too.
All messages received from the addresses included into the Our Users list are marked as submitted by "local" users.
All messages received via AppleTalk SMTP are always marked as submitted by "local" users.
Anti-Spam Options: Black List
If your SMTP module can accept incoming TCP connections, your server can be used by spammers as a mail relay engine: they can distribute their messages all over the world using your server. To protect your site from the known spammer sites, you can put the offending hosts IP addresses into the Black List.
When a host with the address included into the Black List connects to your server and tries to submit a message, it gets an error message from your SMTP module and the message is not accepted.
Click the the Black Listed button. A dialog box appears and allows you to enter the IP addresses of offending hosts.
Each line can contain either one address in the form:
12.34.56.78
or a range of addresses in the form:
12.34.50.01-12.34.59.99
Note: a line can end with the semicolon symbol (";") or a tabulation symbol followed with any text. This "comment" is ignored and it is NOT stored in the settings. This option allows you to copy the "black lists" from other applications or from your Web pages, where IP addresses are followed by short comments:
12.34.56.78-12.34.56.78 ; this host sent a lot of Make Money Fast messages
The addresses included into the Black Lists of Stalker corporate mail servers can be found at:
<http://www.stalker.com/spam/>
Anti-Spam Options: Client Hosts
If your SMTP module can accept incoming TCP connections, your server can be used by spammers as a mail relay engine: they can distribute their messages all over the world using your server. To protect your site from spammers, the system can restrict its relaying functionality.
Shortcut: If all your users use the CommuniGator application, or other AppleTalk-based mailers, simply select the Do not Serve Strangers option.
Shortcut: If you have POP/IMAP users, put the IP addresses they connect from into the Own Users dialog box (see above) and select the Do Not Serve Strangers option.
Advanced Users (and ISPs): Click the Client Hosts button. A dialog box appears and allows you to enter the IP addresses on your LAN, as well as IP addresses of other systems that should be allowed to use your server as a mail relay. For example, if you are an ISP and your mail server is used as a back-up mail server and/or as a forwarding mail server for your client systems, enter the IP addresses of your client servers in the Client Hosts dialog box.
Note: your should not repeat the addresses entered in the Our Users box: mail from those addresses can always be relayed.
Now, when a message is received with the SMTP module via TCP/IP, and the sender IP address is not found neigther in the Our Users list, nor in the Client Hosts list, the message is marked as being received "from a stranger". If this message should be relayed by your server to some other host on the Internet, and that host is not listed in the lists either, the message is rejected.
As a result, servers and workstations listed in the Our Users and Client Hosts lists can use your server to send (relay) messages to anybody on the Internet, and any message from the Internet can be relayed to any listed address (as well as to any CommuniGate user account and to any CommuniGate module). But any message coming from an unlisted system and directed to some other unlisted system will be rejected. This will prohibit spammers from using your server as a mail relay.
Since this functionality can affect your legitimate users if you do not specify their IP addresses correctly, the Do not Serve Strangers option is available. The "stranger-to-stranger" messages are rejected only if this option is selected.
Troubleshooting
If you see that the SMTP module tries to connect to a host, but it fails, or it cannot negotiate with that host, open the SMTP Service Settings and switch the log level to Low-Level Info or to All Info. After the next attempt, switch logging back and examine the CommuniGate Log. If you still cannot find the source of the problem, and the administrator of that host cannot help either, copy that part of the log and E-mail it to <support@stalker.com> with the detailed description of the problem as you see it. Use the About CommuniGate command from the Apple menu of the CommuniGator application to get the information about the versions of your CommuniGate Server and SMTP module. Include that information into your letter.
Routing
The CommuniGate SMTP module is always used as the link to the "rest of the world", i.e. if a message cannot be routed to other modules, and the domain name of the recipient contains dots, the message is routed to the SMTP module. Also, all addresses with a domain name ending with ".smtp" are routed to the SMTP module (with the ".smtp" suffix removed).
The SMTP module recognizes "[xx.yy.zz.tt]" and "xx.yy.zz.tt" domains, where xx.yy.zz.tt is the IP address of your machine, so your system can accept messages even if they were sent using the [xx.yy.zz.tt] notation rather than the domain name notation.
Revision History
2.8 05-Sep-97
• Connection from Black-Listed hosts are not rejected now. Instead, an error message is returned to those hosts when they try to submit a message. This prevents those host from sending messages via your back-up mail servers.
• Comments are allowed in the IP lists, so it is easier to copy Black Listed and other addresses from other documents and/or Web pages.
• Balloon Help is implemented in the Service Settings dialog box.
2.7.2 26-Jul-97
• Changed processing of "temporary problem" responses from a receiving server.
• The 0.0.0.0 IP address is now processed correctly.
• Bug Fix: the module did not operate properly over the AppleTalk (ADSP)
• Bug Fix: some pop-up menu resources were corrupted, it could crash low-end machines when opening the Settings box.
2.7.1 16-Jul-97
• Bug Fix: when a channel setting was set to 1, the related options were disabled.
2.7 10-Jul-97
• The anti-spam protection methods are implemented.
• The "Our Users" option is implemented.
• AppleTalk (ADSP) incoming connections are supported now (under OpenTransport only).
• Multimessage-per-connection protocol is modified to improve compatibility with some old mail servers.
2.6 08-Jun-97
• The module name is changed to SMTP.
• The new STREAMS manager of the CommuniGate Server kernel is used for all communications now.
• The Retry Every option is enabled for the "Foreign mail server" mode (the previous versions used the hard-coded 3 minutes interval).
2.5.1 12-May-97
• The new Apple technique is used to avoid the situation when the SMTP server becomes "deaf".
• Now the module should better detect when a dial-up link is up.
2.5 05-May-97
• The VRFY command is supported.
• Algorithms for SMTP receiving via dial-up lines are improved.
• Communications Services of the CommuniGate Server 2.9 are employed.
2.4 16-Apr-97
• The Always Keep Ready option is implemented.
• The module checks if the Wake-up E-mail address or the Wakeup Host name is entered correctly.
2.3.1 30-Jan-97
• Now if the "Mail From: <>" is received, the Return-Path is stored as NULL, not as NULL@sender.host. This allows to relay the message with the same Mail From: <> when the module acts as a mail relay.
2.3 28-Jan-97
• When creating a channel to process an incoming request (under OpenTransport), there is no more delays if the previous attempt to create a channel failed (as if an outgoing channle could not be created because of the TCP Schedule settings). This is important for using the SMTP module as a LAN SMTP server while outgoing connections are made via dial-up links.
2.2.4 20-Jan-97
• The IP address 127.0.0.1 (local host address) is now processed as one of the local IP addresses.
• Bug Fix: not all fields of the address records where cleaned for received messages. This could result in less attempts to deliver a received message than the limit set in the module settings.
2.2.3 10-Jan-97
• Now if the MX_search operation fails, the module always tries to get the IP address (A-record) of the destination host.
• Bug Fix: when system uses MacTCP and an SMTP connection is broken, the error code was not processed correctly (it could lead to huge dummy files being received and dumped later).
• Bug Fix: when a message transfer failed due to a disk error, the sending was not interrupted correctly.
2.2.2 10-Dec-96
• When creating an OT Listener or opening "waiting" channels under MacTCP, the module uses the high priority calls now, overriding the TCP Schedule options (if the Wait for Connection option is selected). On the systems with a dial-up IP router, it allows the module to serve local SMTP mailers immediately while restricting outgoing SMTP calls with the TCP Schedule. When other than "Wait for Connection" receiving option is used, the listener/incoming channels are created only when the TCP Schedule allows.
• Bug Fix: the number of the OpenTransport IP ports is calculated correctly now.
2.2.1 02-Dec-96
• Bug Fix: the version 2.2 was compiled using new compilers; this resulted in corrupted calls to MacTCP DNR and to "-1" errors on MacTCP systems.
2.2 27-Nov-96
• The retry parameters are configurable now.
• Session closing is modified to compensate bugs in the OpenTransport TCP.
• Checking for "pointing back" DNS records is implemented.
• Numeric domain names (as in postmaster@206.40.74.195) are processed as correctly written IP-style addresses with enclosing brackets.
2.1.1 22-Nov-96
• RFC 1854 (SMTP Pipelining) is implemented.
• Wake-up transactions are marked with the Level 2 Log records (the Major Log Level)
• Session closing is improved
• Bug fix: Retrieveing and storing of local IP addresses under Open Transport is fixed. This bug could result in local mail loops if the server was misconfigured.
• Bug Fix: when a message being transferred was deleted by a local user, the module could loop locking a tcp/ip stream.
2.1 19-Oct-96
• Internal improvements.
• Bug Fix: messages sent to several addresses were not distributed directly.
2.0.2
• Bug Fix: Messages were not sent if the number of outgoing channels was set to 1.
2.0.1
• Support for dial-up connections in the OpenTransport-native mode.
2.0
• Complete redesign of the low-level communication submodule, native OpenTransport implementation (if the OpenTransport TCP is installed).
• Support for DNR searches (when working under OpenTransport) in addition to the "Foreign
mail server" operation mode.
• Queue management changed to employ the CommuniGate Server 2.4 routines.
• Detailed error reporting (now includes the receiving server error messages).
1.7
• Support for RFC1425 (ESMTP) and RFC1985(Remote Queue Starting) is implemented.
1.6
• Redesign of MacTCP reading scheme.
1.5.
• The stream processing has been changed to deal with a set of MacTCP bugs.
• The speed is improved under OpenTransport, and it should be at least as fast under old MacTCP as the version 1.3 was (1.4 was extremely slow under old MacTCP in most of cases).
1.4.
• The wake-up options are implemented to allow receiving mail via SMTP using dial-up links.
• High-priority messages force the Server to establish TCP/IP Links immediately, ignoring the TCP/IP activity schedule.
1.3.
• The CommuniGate Server 2.0 services (MIME, codings, etc) are supported now.
• Mail Coding option is removed (it is in the General Server Settings now).
1.2.1
• Addresses in form of [xx.yy.zz.tt], where xx.yy.zz.tt is the local IP address are processed correctly now.
1.2
• Dial-up links are supported now, the "Sleep Time" option is gone.
• Addresses in form of ip-addresses [xx.yy.zz.tt] are processed properly now.
• Error reporting is improved.
• Bug that caused failures with the -43 error code is fixed
1.1
• The "Sleep Time" option is implemented to support dial-up links.
• Internal changes to allow the SMTPGate to work with Open Transport TCP/IP.
1.0.3
• MacTCP session closing procedure has been changed to improve stability.
• MAIL From: command generating is fixed to avoid "From address rejected" errors.
1.0.2
• MacTCP access scheme has been changed to improve stability and to fix the
problem that resulted in connection failures for various hosts.
1.0.1
• Fixed the Network Coding processing: when this option was set to None, messages
were decoded using a table that did not exist in reality.
